Timing constraints for application specific integrated circuits (ASIC), platform ASICs and field programmable gate array (FPGA) designs are conventionally calculated and set manually. Users extract timing criteria from data sheets of chip-external components and translate the data into constraint syntax according to different timing analysis tool languages. Relationships between data lines going to and coming from the ASIC/FPGA and corresponding clocks have to be understood and carefully described in order to have correct timing constraints.
Determining the timing constraints is especially complicated for inputs/outputs for which the constraints depend on other signals (i.e., clock signals) also coming from the ASIC. The timing criteria are recalculated with every change of the ASIC timing during the process of design completion. For designs that contain several clocks, verification of a quality of the timing constraints is difficult. Verification becomes even more important if a design can operate in different modes, where clock sources, frequencies or dependencies between clock domains can change. Verification of the design coverage is not automated and therefore error prone. The same is true for verification of validity for manually generated constraints (i.e., checking if a data transfer from one clock domain to another would really ever happen).
In engagement models where static timing verification is a shared task between a chip vendor and a customer, or if the customer does not have static timing analysis (STA) tools in-house and therefore seeks help from consultants, generation of a constraint specification becomes a difficult task. In particular, different parties may have completely different understandings of the design “worlds” and a link between the worlds is hard to define. Commonly, one group has a better knowledge about STA for chip internal portions, including physical information and methodology. Another group has a complete overview of the chip environment, including operating modes, board parameters and external component specifications.
In addition to static timing verification, the task of generating constraints for a timing driven cell placement and layout tool is difficult. Conventional tools often only support one set of constraints. Therefore, a mix of different functional modes plus some test criteria are created in one set of constraints that represent a worst case scenario that is often not a real scenario.
The past years have shown that although the above described problems are known, no solution is currently in place. Lessons learned sessions of completed chip projects list the timing constraint topic as an issue for almost every design. The lack of verification tools for the quality of manually generated static timing analysis constraints leaves the verification task to pure visual inspection of the scripts and the reports. The visual inspections often lead to design mistakes.
The process of extracting and translating datasheet information for the chip-external components takes a long time and is error prone. In addition, the extracting and translating are based on abstract understandings of the external connectivity rather than a real schematic that describes the chip environment (i.e., a board layout). The manual process leads to incomplete constraint definitions as elements can be easily overlooked. Furthermore, as signals on chip I/Os are described as coming from or going to virtual places outside the chip under investigation, the timing reports generated by the STA tools (usually in pure ASCII format) are difficult to read and understand.
In engagement models where static timing analysis is shared between different parties, a long time is spent in discussing and understanding the timing criteria from all sides, as people have different technical backgrounds. In addition, long computation runtimes are used to debug the constraints. Debugging the constraints is commonly done only very late in the design flow when sufficient timing information is provided (like standard delay format (SDF) backannotation) to get useful timing reports. Furthermore, scripts are difficult to set up and maintain with many possible sources of errors. Significant valuable engineering resources have to be assigned to complete the scripting tasks.